COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.require "memo.pub[let,jmc]" source
C00027 ENDMK
C⊗;
.require "memo.pub[let,jmc]" source
.cb Old and New Models of the Computerized World of the Future

	Whoever asks someone
to speak about "Where are we going?" should
take into account that the prophet may have prophesied before, and
may have some responsibility to evaluate his old prophecies.
This is the present situation, because today's moderator, Gene
Amdahl, was a discussant when I spoke in an M.I.T. series on
"Management and the Computer of the Future" in 1961.

	Like cars, worlds of the future come in annual models, and
I shall begin with the durability of my 1961 model.


A 1961 model world of the future.

	The 1961 future was time-sharing.  The concept was of a computer
system in which each user at his terminal could behave as though he had a
whole computer at his disposal, not concerning himself with other users.
I proclaimed this superior to batch processing, the current mode of
running computers in which a user prepared a deck of cards using a
keypunch and an operator put it on magnetic tape in sequence with the jobs
of other users.  Several hours to several days later, the user would get
back output.  My discussion concerned the scientific or engineering
programmer, who needed to write and debug programs.  It did not emphasize
the user of already prepared programs.

	In 1961 there were no general purpose time-sharing systems,
although there were systems that time-shared between various jobs
that had been debugged to run together.  An important example was
the SAGE air defense system which time-shared among radars and
people with titles like "Senior Weapons Controller" who sat at
special purpose terminals pushing buttons that told fighter pilots
where they would find the bombers.

	The novelty was to provide for running undebugged machine
language programs together.  This required memory protection and
relocation and a user mode that couldn't directly initiate input-output.
It also required a time-sharing operator system.  However,
both Gene Amdahl and the other discussant, the late John Mauchly
who was one of the inventors of stored program computers, agreed
on the desirability and feasibility of time-sharing.

	At the time, I believed that time-sharing would become
the dominant means of using computers by 1965, but it happened
much more slowly.  Experimental systems were working in 1962 at
M.I.T. and at Bolt, Beranek and Newman, and the large scale experimental
system CTSS ready for substantial use by the summer of 1964.
  Our Artificial Intelligence Laboratory at
Stanford developed a time-sharing system in 1963 and 1964, and
we were able to buy a commercial time-sharing system from Digital
Equipment Corporation in 1965.  However, the undergraduate
computing at Stanford did not switch from batch processing to
time-sharing until 1976, and most other schools switched somewhat
later.  (The above are examples rather than a capsule history of
time-sharing).

	There are still important bastions of batch processing
in the commercial world, and this technological fact has a social
consequence.  Consider, for example, a billing system in which
the status of the various accounts is kept on magnetic tape,
each tape storing the data for thousands of accounts.  If a
customer complains of an error, the clerks have no direct
access to the record.  They must refer to a printed report, and
one possible error is a discrepancy between the printed report
and the tape file.  For example, the wrong tape may have been used.
Correcting the error requires making a card to modify the record
and waiting for the next update run.  Checking that the correction
has been made correctly must await the next printout of the
account records.  No wonder persistent errors aren't rare, and
no wonder the clerks and complaint people blame the computer.
In a sense they are correct in doing so.

	Contrast this with an on-line system in which the
account is on disk file that is always directly accessible to
the clerks.  A recognized error can be corrected immediately,
and the new record can immediately be inspected.  Today there
are many on-line systems, but there are still many too batch
systems giving computers a bad name.

	Why has it taken so long for the time-sharing mode of computer
operation to become dominant, and why is the process still incomplete?
Here are some speculations.

	1. There were no operating time-sharing systems in 1961.
The first experimental systems were a year later, and the Digital
Equipment Corporation PDP-6 didn't become available until 1964,
and then it wasn't entirely satisfactory.

	2. Time-sharing turned out to require greater computer
resources than anticipated.  This is partly a fact of technology,
but it is partly a psychological fact.  Computer scientists and
hackers have shown great interest in adding features to time-sharing
and other on-line systems and almost no interest in finding
the sources of inefficiency and correcting them.  To give a technical
example, in one of our systems at Stanford, the time required for
the system to open a file is proportional, for no good reason,
to the number of files already open.  With a small number of users
on the machine the effect is not noticeable, but when one
buys a compatible machine five times as fast, one is unpleasantly
surprised that, for unknown reasons, it won't handle five times
as many users with the same service.

	3. IBM's new computer of the 1960s, the 360, did not have
the relocation features required for time-sharing except in the special
Model 67.  These features became standard only in the middle 1970s.
Gene Amdahl can say better than I can how this came about.
We are still suffering from this mistake today, because, according
to my informants, many companies are still wedded to older IBM
software in which time-sharing is grafted onto a basically batch
system.

	4. IBM followed M.I.T. into the swamp of over-elaboration
in their time-sharing systems of the middle 1960s.  The reader is
warned that this opinion may not receive universal assent.

	5. I must confess that my 1961 paper does not offer any
arguments for the importance of on-line operation
in the commercial uses of computers, although I had had the thought.
My interest was in scientific computation where the first successful
debugging run of a program is often the only production run.  It
would be interesting to know when the arguments for commercial
on-line systems - other than reservation systems - were first
advanced.  It would be also interesting to know if there have been
social arguments in addition to ordinary commercial arguments.


A 1965 model world of the future.

	Now let me turn to a 1965 model world of the future.  I
thought it was Paul Baran's, but it isn't in the paper where I
remembered it to be.  He remembers it vaguely but isn't sure
whether it was his.

	A clerk in Company A hears a beep and turns to her terminal.
On the screen there is a message from the inventory control computer
saying: "We need 5000 number 2 pencils.  Please order them from
Company B".  The clerk turns to her typewriter and types a purchase
order and mails it.  In Company B, another clerk reads the purchase
order, turns to her terminal and types: "Send Company A 5000 number
3 pencils and a bill".

	As far as I can remember, this world was depicted with
a perfectly straight face.  Moreover, it was an excellent prophecy.
In the main that world has arrived.


1983 model worlds of the future.

	The first 1983 model relates to the 1965 model.  How are the
two computers going to talk to each other directly while the
former clerks loll on the beach?  They are going to talk to each
other in CBCL (the Common Business Communication Language).
See (McCarthy 1982) if you can find it.

	CBCL is intended as a language in which a computers belonging
to Companies A and B can conduct such dialogs as:

	A: What is your price for number 2 pencils?

	B: α$1.13 per gross plain and α$1.40 per gross with your message
provide at least 100 gross are ordered.

	A: I hereby order (authorization 30621) 1000 gross with the
message "A fool and his money are soon parted".  We propose standard
commercial contract 361.

	B: How do you want them delivered?

	A: 100 gross per month starting in 1990 January.

	B: I accept your order authorization 30621.  My authorization
is 77522.

	This dialog is more elaborate than most transactions
will require, but it is designed
to illustrate some of the problems and issues.
At first I thought the CBCL problem was a simple matter of standardization
like the universal product code.  A committee of the American Standards
Association could hold meetings for three or four years, produce a
document, and then manufacturers could implement systems that would
communicate in accordance with the protocols.  This was a mistake.
The problem is rather to define the semantics of a substantial
and interesting subset of English.  Here are some of the points that
arose.

	1. Since the communication is between computers, there is no
reason to use English syntax.  In fact I believe that a LISP type
syntax is suitable.  Each non-atomic part of the message is a list,
and the first element of the list identifies the overall meaning
of the part.  We thus have (PENCIL (TYPE: "NUMBER 2")) as an item
and perhaps (PENCIL (TYPE: "NUMBER 2") (WITH (MESSAGE "A fool and
his money are soon parted"))).

	2. Most work on making computers use English has involved
making the computer send and receive the usual kinds of messages
people receive from and send to computers - only expressing them
in English.  The business communication problem involves messages
whose content is presently only expressed in English but where we
are willing to use any kind of formalism convenient to program.
In my view, contrary to what I take to be the Chomskyan emphasis on
syntax, the second problem is scientifically more interesting, though
admittedly more difficult.  My fellow AI people have also found it
more convenient to concentrate on syntax.

	In summary, broadening the usefulness of computers in the
next 22 years, will require making them communicate substantively
with each other.  This will require the understanding and the
formalization of an interesting part of the semantics (not the
syntax) of natural language.


Another (though related) world of the future.

	More and more, the general public will find itself interacting
directly with computers.  There will be personal computers, but there
will also be computers belonging to the sellers of products and
services, to various levels of government and to educational and
other private organizations.  Much useful interaction can be carried
out with a level of understanding of computers corresponding to
the understanding of electricity required to use a light switch.
However, many useful services that computers can perform are
complex in their interaction and what a user must understand
about their internal state is complex.

	Fortunately, we humans already have language suited to expressing
our understanding much about the internal states of computer based
systems.  This is the naive psychological language used to express what
people know about each other.  I begin with an overly simple illustrative
example:

%2"Place the control near the bed in a place that is neither hotter nor
colder than the room itself.  If the control is placed on a radiator or
radiant heated floors, it will "think" the entire room is hot and will
lower your blanket temperature, making your bed too cold.  If the control
is placed on the window sill in a cold draft, it will "think" the entire
room is cold and will heat up your bed so it will be too hot."%1 - from the
instructions to an electric blanket.

	The manufacturers of the blanket imagined that some of their customers
would know less and would be helped by the psychological language.
We who understand thermostats don't need to refer to what
the thermostat "thinks", because the language of machinery is adequate.
However, I will maintain that the usage is legitimate and may be useful
in relation to the blanket and that it will be almost essential to
express what people need to know about certain important computer
based systems.

	The issue isn't whether the thermostat "really thinks".  We
merely observe that there is a useful correspondence between
a person being misled by observation and the thermostat measuring
the temperature of the radiator when it should have been measuring
the temperature of the room.

	We will find ourselves referring to what the computer
⊗knows, ⊗believes, ⊗intends, ⊗expects, ⊗promises and ⊗wants.
The finicky may begin by putting ⊗pseudo- in front of each of
these words, but they'll soon get tired of it.  Such usage
will help us form and express our expectations of what use we can get out
of a particular computer system.  Computers will turn out to
have varied little minds, and wholesale ascription of mental
qualities will be unwarranted.  The thermostat cannot usefully
be said to know that it believes the room is too hot and it cannot
⊗realize that it was mistaken; it merely comes to have a different
belief.  I don't think we will find it in our interest to build
machines that can be reasonably said to ⊗suffer, ⊗love, or ⊗have ⊗rights. 

	Here is a more significant example:

	%2I asked the computer whether it could run my job at 4pm.
It said it could but it probably wouldn't.  At that point it crashed
so I couldn't ask more questions.  I don't know whether it thought
I was unauthorized or had exceeded my quota of resources.  I also
don't know whether it intends to run the job later%1.

	Some of these philosophically controversial issues are
discussed in (McCarthy 1979).


References:

%3McCarthy, John (1962)%1: "Time-Sharing Computing Systems," in %2Management
and the Computer of the Future%1, Martin Greenberger (ed.), MIT Press.

%3McCarthy, John (1979)%1:
"Ascribing Mental Qualities to Machines" in %2Philosophical Perspectives 
in Artificial Intelligence%1, Ringle, Martin (ed.), Harvester Press, July 1979.
.<<aim 326, MENTAL[F76,JMC]>>

.begin
.FONT B "zero30";

%3McCarthy, John (1982)%1: "Common Business Communication Language", in
%2Textverarbeitung und B%B:%*urosysteme%1, Albert Endres and J%B:%*urgen Reetz, eds.
R. Oldenbourg Verlag, Munich and Vienna 1982.
.end

.begin verbatim

John McCarthy
Computer Science Department
Stanford University
Stanford, California 94305
.end verbatim
.<< chicag[w83,jmc]>>